(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(11) 



EP 1 361 706 A2 



(12) 



EUROPEAN PATENT APPLICATION 



(43) 


Date of publication: 


/5i\ intci 7 H04L 12/56 H04L PQ/Ofi 

\%J 1 f fill Ol . . 1 IV^L 1 £—i \J \J , 1 1 \J*T l_ L— \JI \J\J 




12.11.2003 Bulletin 2003/46 


(21) 


Application number: 03001884.0 




(22) 


Date of filing: 29.01 .2003 




(84) 


Designated Contracting States: 


(72) Inventor: Wu, Frank Chih-Hsiang 




AT BE BG CH CY CZ DE DK EE ES Fl FR GB GR 


Shindtan City, Taipei (TW) 




HU IE IT LI LU MC NL PT SE SI SK TR 






Designated Extension States: 


(74) Representative: 




AL LT LV MK RO 


TER MEER STEIN MEISTER & PARTNER GbR 






Patentanwalte, 


(30) 


Priority: 10.05.2002 US 319240 P 


Mauerkircherstrasse 45 






81679 Milnchen (DE) 


(71) 


Applicant: ASUSTeK Computer Inc. 






Peitou, Taipei City (TW) 





(54) Method for determining triggering of a pdep sequence number synchronization prodecure 



(57) When an RRC procedure is combined with an 
SRNS Relocation procedure, a PDCP synchronization 
procedure is performed only if a next expected UL/DL 
Receive PDCP sequence number invalidity event is de- 
tected during the SRNS Relocation procedure. If no 
such invalidity event is detected, then no PDCP se- 
quence number synchronization procedure is per- 



formed. If the RRC procedure is not executed in combi- 
nation with the SRNS Relocation procedure, then the 
PDCP sequence number synchronization procedure is 
performed only if: (1) The RRC procedure causes the 
RLC entity that is used by the PDCP entity to be re-es- 
tablished; or, (2) The RRC procedure causes the header 
compression protocol used by the PDCP entity to be 
changed. 
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Description 

CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] The application claims the benefit of U.S. Pro- 
visional Application No. 60/319,240, filed 05/10/2002, 
and included herein by reference, 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0002] The present invention relates to a wireless 
communications network. In particular, the present in- 
vention discloses a method for determining when a 
packet data convergence protocol (PDCP) sequence 
number synchronization procedure should be per- 
formed. 

2. Description of the Prior Art 

[0003] Please refer to Fig.1 . Fig.1 is a block diagram 
of a wireless communications network 1 0, as defined by 
the 3 rd Generation Partnership Project (3GPP) specifi- 
cations 3GPP TS 25.322 V3.10.0 "RLC Protocol Spec- 
ification", 3GPP TS 25.331 V3.10.0 "Radio Resource 
Control (RRC) Specification", and 3GPP TS 25.303 
V3.11.0 "Interlayer procedures in Connected Mode", 
which are included herein by reference. The wireless 
communications network 1 0 comprises a plurality of ra- 
dio network subsystems (RNSs) 20 in communications 
with a core network (CN) 30. The plurality of RNSs 20 
is termed a Universal Mobile Telecommunications Sys- 
tem (UMTS) Terrestrial Radio Access Network, or 
UTRAN for short. Each RNS 20 comprises one radio 
network controller (RNC) 22 that is in communications 
with a plurality of Node Bs 24. Each Node B 24 is a trans- 
ceiver, which is adapted to send and receive wireless 
signals*. In particular, the wireless communications net- 
work 10 assigns a mobile unit 40 (generally termed a 
"UE" for User Equipment) to a particular RNS 20, which 
is then termed the serving RNS (SRNS) 20s of the UE 
40. Data destined for the UE 40 is sent by the CN 30 to 
the SRNS 20s. This data is in the form of service data 
units (SDUs) 28 that are held by the RNC 22 of the 
SRNS 20s pending transmittal by one of the Node Bs 
24. The RNC 22 selects a Node B 24 that is best able 
to accurately transmit the SDUs 28 to the UE 40. Such 
a selection will depend, for example, upon the location 
of the UE 40 within the domain of the SRNS 20s. The 
U E 40 broadcasts SDUs 48 to the wireless communica- 
tions network 1 0, which are then picked up by the SRNS 
20s and forwarded to the CN 30. Occasionally, the UE 
40 may move close to the domain of another RNS 20, 
which is termed a drift RNS (DRNS) 20d. A Node B 24 
of the DRNS 20d may pick up the signal transmitted by 
the UE 40. The RNC 22 of the DRNS 20d forwards the 
received signal to the SRNS 20s. The SRNS 20s uses 



this forwarded signal from the DRNS 20d, plus the cor- 
responding signals from its own Node Bs 24 to generate 
a combined signal that is then decoded and finally proc- 
essed into SDUs 28. The SRNS 20s then forwards these 
5 received SDUs 28 to the CN 30. Consequently, all com- 
munications between the UE 40 and the CN 30 must 
pass through the SRNS 20s. 

[0004] Please refer to Fig.2 in conjunction with Fig.1 . 
Fig.2 is a simple block diagram of the UMTS radio inter- 
ne face protocol architecture. Communications between 
the UE 40 and the UTRAN 20u is effected through a 
multi-layered communications protocol that includes a 
layer 1 , a layer 2 and a layer 3, which together provide 
transport for a signaling plane (C-plane) 92 and a user 

is plane (U-plane) 94. Layer 1 is the physical layer 60, and 
in the UTRAN 20u is responsible for combining signals 
received from the DRNS 20d and SRNS 20s. Layer 2 
includes a packet data convergence protocol (PDCP) 
layer 70, a Radio Link Control (RLC) layer 72, and a Me- 

20 dium Access Control (MAC) layer 74. Layer 3 includes 
a Radio Resource Control (RRC) layer 80. The U-plane 
94 handles user data transport between the UE 40 and 
the UTRAN 20u, whereas the C-plane 92 handles trans- 
port for signaling data between the UE 40 and the 

25 UTRAN 20u. The RRC 80 sets up and configures all 
channels between the UTRAN 20u and the UE 40. The 
PDCP layer 22 provides header compression for Serv- 
ice Data Units (SDUs) received from the U-plane 94 to 
increase bandwidth utilization efficiency. The RLC layer 

30 72 provides segmentation and concatenation of PDCP 
70 SDUs and RRC 80 SDUs into RLC protocol data 
units (RLC PDUs), and under acknowledged mode (AM) 
transfers, can provide upper layers (such as the PDCP 
layer 70 or the RRC layer 80) with a confirmation that 

35 RLC PDUs have been successfully transmitted and re- 
ceived between the UTRAN 20u and the UE 40. The 
MAC layer 74 provides scheduling and multiplexing of 
RLC PDUs onto the transport channel, interfacing with 
the physical layer 60. 

40 [0005] Before proceeding, it is worth taking note of ter- 
minology used in the following. An SDU is any packet 
that is received from an upper layer or passed to an up- 
per layer, whereas a PDU is a packet generated by a 
layer and passed on to a lower layer or received from a 

45 lower layer. Hence, a PDCP PDU is an RLC SDU. Sim- 
ilarly, an RLC PDU is a MAC SDU, and so forth. As such, 
whether a packet is termed a "PDU" or an "SDU" will 
depend upon the point of view of the layer being con- 
sidered. In general, each layer will add information, typ- 

50 ically in the form of a header, to SDU data to generate 
a PDU. 

[0006] Each PDCP PDU generated by the PDCP lay- 
er 70 in response to an SDU received from the U-plane 
94 is incrementally assigned a 16-bit sequence number 
55 (SN) by the PDCP layer 70 if a so-called lossless prop- 
erty is configured for the connection. That is, each se- 
quentially successive PDCP PDU generated by the PD- 
CP layer 70 is assigned an incrementally higher SN. For 
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example, at a given instant in a stream of PDCP PDUs, 
a first PDCP PDU may be assigned an SN of 62 by the 
PDCP layer 70. A second PDCP PDU generated imme- 
diately after the first PDCP PDU would thus be assigned 
an SN of 63, and so on . When a PDCP entity is first set- 
up, the first PDCP PDU of the entity has an SN of zero. 
The SNs are not actually a part of the PDCP PDUs, but 
are internally maintained by the PDCP layer 70. The PD- 
CP PDUs are then delivered to the RLC layer 72 for 
transmission. Since bandwidth is to be maximized by 
the compression of the U-plane SDU headers, each PD- 
CP PDU should, ideally, be smaller in size than its cor- 
responding U-plane SDU. To ensure that this is indeed 
the case, the PDCP headers should be kept as small as 
possible, and to provide for this, PDCP SNs are gener- 
ally not transmitted in their associated PDCP PDUs. 
Similarly, each PDCP PDU received from the RLC layer 
72 is incrementally assigned an SN by the PDCP layer 
70. Hence, two unique sets of PDCP SNs exist: one for 
PDCP PDUs received from the RLC layer 72, and an- 
other for PDCP PDUs generated from U-plane 94 
SDUs. 

[0007] As the UE 40 moves closer towards the do- 
main of the DRNS 20d, a decision is eventually made 
by the wireless network 1 0 to place the U E 40 under the 
DRNS 20d, and a transfer process is enacted. This proc- 
ess is termed an SRNS relocation procedure, and under 
certain transport modes is a lossless procedure. Loss- 
less means that no PDCP SDUs 28, 48 are lost during 
the relocation procedure. Please refer to Fig. 3 in con- 
junction with Figs.1 and 2. Fig.3 is a block diagram of 
the UE 40 undergoing a lossless SRNS relocation pro- 
cedure. The DRNS 20d becomes a target RNS (TRNS) 
20t. After completion of the relocation procedure, the 
TRNS 20t will serve as the new SRNS 20s for the UE 
40. In order for the TRNS 20t to properly take up its job 
as the new SRNS 20s for the UE 40, the current SRNS 
20s must forward key information to the TRNS 20t. 
Please refer to Fig. 4 in conjunction with Figs. 2 and 3. 
Fig. 4 is a message sequence chart for the prior art loss- 
less SRNS relocation procedure. The SRNS 20s sends 
forwarding information 50 to the TRNS 20t. This for- 
warding information includes a downlink sending se- 
quence number (DL Send_SN) 52, an uplink receiving 
sequence number (UL Receive_SN) 54, and all uncon- 
firmed PDCP SDUs 28. The multi-layered communica- 
tions protocol used by both the SRNS 20s and the UE 
40 enables the UE 40 to confirm those PDCP PDUs 
transmitted by the SRNS 20s that are successfully re- 
ceived by the UE 40. Any PDCP PDUs not explicitly con- 
firmed as received by the UE 40 are termed unconfirmed 
PDCP PDUs. As each PDCP SDU 28 has a correspond- 
ing PDCP PDU, an unconfirmed PDCP PDU generally 
means that there is a corresponding unconfirmed PDCP 
SDU 28. These unconfirmed PDCP SDUs 28 are for- 
warded by the SRNS 20s to the TRNS 20t. The DL 
Send_SN 52 is the value of the SN associated with the 
sequentially earliest unconfirmed PDCP SDU. As the 
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SNs are not explicitly carried in the PDCP PDUs, this 
enables the PDCP layer 70 in the TRNS 20t to properly 
associate an SN for the corresponding PDCP PDU of 
each forwarded PDCP SDU 28. The UL Receive.SN 54 
5 is the value of the SN associated with a PDCP SDU that 
the SRNS 20s next expects to receive from the UE 40. 
This enables the TRNS 20t to properly associate an SN 
for each PDCP SDU subsequently received from the UE 
40. The TRNS 20t sends the UL Receive_SN 54 to the 
10 UE 40. From this, the U E 40 can determine which PDCP 
SDUs to begin sending to the TRNS 20s under its guise 
as the new SRNS 20s. The UE 40 sends a downlink 
receiving sequence number (DL Receive_SN) 58 to the 
TRNS 20s. The DL Receive_SN 58 holds the value of 
15 the SN of the next PDCP SDU that the UE 40 is expect- 
ing to receive from the TRNS 20t. From this, the TRNS 
20tcan learn which of the forwarded unconfirmed PDCP 
SDUs 28 to begin sending to the UE 40. Consider, as 
an example, a situation in which the SRNS 20s has sent 
PDCP PDUs, each of which has a corresponding PDCP 
SDU, to the UE 40 having associated SNs running from 
0 to 99. We may further assume that, of these 1 00 PDCP 
PDUs sent, only those with SNs running from 0 to 50 
were confirmed by the UE 40. Consequently, there are 
unconfirmed PDCP PDUs with SNs running from 51 to 
99, each of which has a corresponding unconfirmed PD- 
CP SDU 28. Also, the SRNS 20s has received 200 PD- 
CP PDUs, each of which has a corresponding PDCP 
SDU, from the UE 40, with SNs running from 0 to 199. 
In the SRNS relocation procedure, the PDCP SDUs 28 
with associated SNs running from 51 to 99 are forward- 
ed by the SRNS 20s to the TRNS 20t. The DL Send_SN 
52 would have a value of 51 , and the UL Receive_SN 
54 would have a value of 200. The DL Receive_SN 58 
will hold a value that is between 51 and 1 00, depending 
on how many of the unconfirmed PDCP PDUs were ac- 
tually received by the UE 40, but not yet confirmed. If, 
for example, the DL Receive_SN 58 holds a value of 90, 
then the TRNS 20t knows that it may discard the for- 
warded PDCP SDUs 28 that have associated SNs that 
run from 51 to 89, and will begin transmitting those for- 
warded PDCP SDUs 28 with associated SNs that are 
from 90 and above. Although it should not happen, it is 
possible that the DL Receive_SN 58 will either be se- 
quentially before the DL Send_SN 52 or sequentially af- 
ter the SN associated with the sequentially last forward- 
ed PDCP SDU 28. Similarly, it is possible for the UL 
Receive_SN 54 to be sequentially before the last PDCP 
PDU that that UE 40 considered confirmed as success- 
fully transmitted, or sequentially after the SN of the PD- 
CP PDU that the UE 40 next expects to send to the 
UTRAN 20u. Any such occurrence of the above means 
that the SNs maintained by the RNC 22 of the SRNS 
20s are out of synchronization with corresponding SNs 
maintained by the UE 40, and is herein termed a "next 
expected UL/DL Receive PDCP sequence number in- 
validity event". A PDCP sequence number synchroniza- 
tion procedure is thus enacted by the TRNS 20t, or by 
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the UE 40, depending upon which device detects the 
next expected UL/DL Receive PDCP sequence number 
invalidity event. During the PDCP sequence number 
synchronization procedure (and assuming for the sake 
of example that it is the TRNS 20t that has detected the 
next expected UL/DL Receive PDCP sequence number 
invalidity event), the TRNS 20t transmits a PDCP PDU 
that explicitly contains its associated SN in its PDCP 
header, with the data region of this PDCP PDU corre- 
sponding to the sequentially earliest forwarded PDCP 
SDU 28. This PDU is termed a PDCP SeqNum PDU. 
Once the UE 40 has confirmed this PDCP SeqNum PDU 
(by way of the RLC layer 72), the TRNS 20t considers 
the PDCP sequence number synchronization proce- 
dure completed. 

[0008] The primary purpose of having PDCP PDU 
SNs is to support lossless SRNS relocation, as dis- 
cussed above. Unsynchronization of PDCP SNs be- 
tween two PDCP entities (i.e., the UE 40 and the 
UTRAN 20u) can lead to PDCP PDU loss. The PDCP 
sequence number synchronization procedure as dis- 
cussed above avoids such loss. In all cases in the prior 
art, it is the RRC layer 80, in either the UTRAN 20u or 
the UE 40, that instructs the PDCP layer 70 to perform 
the PDCP sequence number synchronization proce- 
dure. The prior art notes three cases in which the RRC 
layer 80 should cause a PDCP sequence number syn- 
chronization procedure to occur: 

1) During an RLC reset procedure. 

2) During a Radio Bearer reconfiguration proce- 
dure. 

3) During a lossless SRNS relocation when a next 
expected UL/DL Receive PDCP sequence number 
invalidity event is detected between the sequence 
numbers of the two PDCP entities. 

[0009] Under certain conditions, the Radio Bearer 
reconfiguration procedure will not lead to loss of PDCP 
PDUs. Nevertheless, the prior art protocol insists that a 
PDCP sequence number synchronization procedure be 
performed. This is a waste of radio resources, as it forc- 
es the unnecessary inclusion of the 16-bit PDCP se- 
quence number into the transmitted PDCP PDUs. Sec- 
ondly, when the Radio Bearer reconfiguration procedure 
is combined with the SRNS Relocation procedure, the 
prior art further insists that the PDCP sequence number 
synchronization procedure be performed, even if no 
next expected UL/DL Receive PDCP sequence number 
invalidity event has been detected. Again, this wastes 
radio resources. Finally, there are other RRC proce- 
dures besides the Radio Bearer reconfiguration proce- 
dure that can lead to loss of PDCP PDUs, and which are 
unaccounted for in the prior art. This can undermine the 
entire lossless SRNS Relocation procedure of the prior 
art, if these RRC procedures are not performed in com- 
bination with an SRNS Relocation procedure. 



SUMMARY OF THE INVENTION 

[001 0] It is therefore a primary objective of this inven- 
tion to provide a method for determining when a PDCP 
s sequence number synchronization procedure should be 
performed. 

[001 1 ] Briefly summarized, the preferred embodiment 
of the present invention considers RRC procedures that 
can be combined with an SRNS Relocation procedure, 

10 and which can potentially lead to the loss of PDCP 
PDUs. These procedures include Transport Channel 
Reconfiguration, Radio Bearer Setup, Radio Bearer Re- 
lease, and Cell Update procedures. Further, each of 
these RRC procedures is capable of causing the RLC 

15 peer entities associated with the PDCP peer entities to 
be re-established. When the RRC procedures are com- 
bined with the SRNS Relocation procedure, a PDCP 
synchronization procedure is performed only if a next 
expected UL/DL Receive PDCP sequence number in- 

20 validity event is detected during the SRNS Relocation 
procedure. If no next expected UL/DL Receive PDCP 
sequence number invalidity event is detected, then no 
PDCP sequence number synchronization procedure is 
performed. If the RRC procedures are not executed in 

25 combination with the SRNS Relocation procedure, then 
the PDCP sequence number synchronization proce- 
dure is performed under the following cases: 

1) The RRC procedure causes the RLC entity that 
30 is used by the PDCP entity to be re-established. Or, 

2) The RRC procedure causes the header compres- 
sion protocol used by the PDCP entity to be 
changed. 

35 [001 2] It is an advantage of the present invention that 
by only performing the PDCP sequence number syn- 
chronization procedure when a next expected UL/DL 
Receive PDCP sequence number invalidity event is de- 
tected during an S RNS Relocation procedure, unneces- 

40 sary inclusion of the 16-bit PDCP sequence numbers 
into the PDCP PDUs is avoided, thereby reducing the 
amount of data that needs to be transmitted for each 
PDCP SDU, and thus increasing the bandwidth utiliza- 
tion efficiency Similarly, when the RRC procedures are 

45 performed alone and not in combination with an SRNS 
Relocation procedure, by only performing the PDCP se- 
quence number synchronization procedure when the 
RRC procedure has possibly caused loss of PDCP 
PDUs, unnecessary executions of the PDCP sequence 

50 number synchronization procedure are avoided, thus in- 
creasing the bandwidth utilization efficiency. Finally, by 
considering all RRC procedures that can potentially lead 
to loss of PDCP PDUs, the present invention better en- 
sures that a lossless SRNS Relocation procedure can 

55 be performed. 

[0013] These and other objectives of the present in- 
vention will no doubt become obvious to those of ordi- 
nary skill in the art after reading the following detailed 
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description of the preferred embodiment, which is illus- 
trated in the various figures and drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] 

Fig.1 is a block diagram of a wireless communica- 
tions system. 

Fig.2 is a simple block diagram of a UMTS radio 
interface protocol architecture. 
Fig.3 is a block diagram of a mobile unit of Fig.1 
undergoing a lossless SRNS relocation procedure. 
Fig.4 is a message sequence chart for a prior art 
lossless SRNS relocation procedure. 
Fig.5 is a simple block diagram of a UMTS radio 
interface protocol architecture according to the 
present invention. 

Fig. 6 is a simplified message sequence chart for 
performing an RRC Cell Update procedure in com- 
bination with an SRNS Relocation procedure ac- 
cording to the present invention. 
Fig. 7 is a simplified message sequence chart for 
performing an RRC URA Update procedure in com- 
bination with an SRNS Relocation procedure ac- 
cording to the present invention. 
Fig. 8 is a simplified message sequence chart for 
performing an RRC Radio Bearer Setup procedure 
in combination with an SRNS Relocation procedure 
according to the present invention. 
Fig.9 is a simplified message sequence chart for 
performing an RRC Radio Bearer Release proce- 
dure in combination with an SRNS Relocation pro- 
cedure according to the present invention. 
Fig.1 0 is a message sequence chart for performing 
an RRC Transport Channel Reconfiguration proce- 
dure in combination with an SRNS Relocation pro- 
cedure according to the present invention. 
Fig.1 1 is a message sequence chart for performing 
an RRC Radio Bearer Reconfiguration procedure 
in combination with an SRNS Relocation procedure 
according to the present invention. 
Fig.1 2 is a message sequence chart for performing 
an RRC Physical Channel Reconfiguration proce- 
dure in combination with an SRNS Relocation pro- 45 
cedure according to the present invention. 
Fig.1 3 is a message sequence chart for performing 
an RRC UTRAN Mobility Information procedure in 
combination with an SRNS Relocation procedure 
according to the present invention. so 
Fig.1 4 is a first simplified message sequence chart 
according to the present invention for performing an 
RRC Radio Bearer Reconfiguration procedure with- 
out performing an SRNS Relocation procedure. 
Fig.1 5 is a second simplified message sequence 55 
chart according to the present invention for perform- 
ing an RRC Radio Bearer Reconfiguration proce- 
dure without performing an SRNS Relocation pro- 
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cedure. 

Fig. 16 is a first simplified message sequence chart 
according to the present invention for performing an 
RRC Transport Channel Reconfiguration proce- 
dure without performing an SRNS Relocation pro- 
cedure. 

Fig. 17 is a first simplified message sequence chart 
according to the present invention for performing an 
RRC Radio Bearer Setup procedure without per- 
forming an SRNS Relocation procedure. 
Fig. 18 is a second simplified message sequence 
chart according to the present invention for perform- 
ing an RRC Radio Bearer Setup procedure without 
performing an SRNS Relocation procedure. 
Fig. 19 is a first simplified message sequence chart 
according to the present invention for performing an 
RRC Radio Bearer Release procedure without per- 
forming an SRNS Relocation procedure. 
Fig.20 is a second simplified message sequence 
chart according to the present invention for perform- 
ing an RRC Radio Bearer Release procedure with- 
out performing an SRNS Relocation procedure. 
Fig.21 is a first simplified message sequence chart 
according to the present invention for performing an 
RRC Cell Update procedure without performing an 
SRNS Relocation procedure. 
Fig. 22 is a second simplified message sequence 
chart according to the present invention for perform- 
ing an RRC Cell Update procedure without perform- 
ing an SRNS Relocation procedure. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

[0015] In the following description, user equipment 
(UE) may be a mobile telephone, a handheld transceiv- 
er, a personal data assistant (PDA), a computer, or any 
other device that requires a wireless exchange of data. 
It is assumed that this wireless exchange of data con- 
forms to 3GPP-specified protocols. It should be under- 
stood that many means may be used for the physical 
layer to effect wireless transmissions, and that any such 
means may be used for the system hereinafter dis- 
closed. 

[0016] Please refer to Fig.5. Fig.5 is a simple block 
diagram of a UMTS radio interface protocol architecture 
according to the present invention. The basic structure 
of the present invention UMTS radio interface protocol 
architecture is much like that of the prior art, and is im- 
plemented in both the UTRAN and the UE. Specifically, 
a three-layered interface is provided, with the layer 3 
interface including an RRC layer 101. However, the 
present invention RRC layer 101 includes a PDCP re- 
synchronization module 101 r that causes the RRC layer 
101 to instruct a PDCP layer 102 in the layer 2 interface 
to perform PDCP sequence number synchronization 
procedures only when certain specific RRC 101 proce- 
dures are performed under specific circumstances. The 
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PDCP re-synchronization module 1 01 r is depicted in 
Fig.5 as being part of the RRC layer 1 01 . One skilled in 
the art, though, should quickly realize that the re-syn- 
chronization module 101 r may be effectively disposed 
anywhere within a present invention wireless device, as 
the re-synchronization module is preferably implement- 
ed by way of software. These specific RRC 101 proce- 
dures and their related circumstances will be treated in 
more detail below, but include the following RRC 1 01 
procedures: Transport Channel Reconfiguration, Radio 
Bearer Setup, Radio Bearer Release, Cell Update, RRC 
Radio Bearer Reconfiguration, URA Update, and 
UTRAN mobility information. All of these RRC 101 pro- 
cedures are characterized in that they can perform, or 
be combined with, an SRNS relocation procedure. Fur- 
ther, all of these RRC 101 procedures, except for the 
URA Update and UTRAN Mobility Information proce- 
dures, are capable of causing the RLC layer 103 asso- 
ciated with the PDCP layer 1 02 to be re-established, and 
hence lead to a potential loss of untransmitted RLC 1 03 
PDUs. These RRC 101 procedures are also capable of 
causing the PDCP 102 header compression protocol to 
be changed, which leads to discarding of PDCP 102 
PDUs. Thus, all of the RRC 101 procedures are ulti- 
mately characterized in that they can potentially lead to 
a loss of PDCP 102 PDUs. 

[0017] Each of the above-noted RRC 1 01 procedures 
is initiated by passing an associated RRC 1 01 message 
between RRC 101 peer entities (i.e., between the RRC 
101 of the UE and the corresponding RRC 101 of the 
UTRAN). The RRC 1 01 procedures are capable of per- 
forming SRNS Relocation by including an information 
element (IE) in the related RRC 101 message. By in- 
cluding a "new U-RNTI" IE in the Radio Bearer Recon- 
figuration message, the UTRAN commands the UE to 
change the SRNS of the UE. If the "new U-RNTI" IE is 
not included in the Radio Bearer Reconfiguration mes- 
sage, then SRNS Relocation is not performed (i.e. is not 
combined with the RRC 101 Radio Bearer Reconfigu- 
ration procedure). A "Downlink counter synchronization 
info" IE is included in the other RRC 101 messages 
(Transport Channel Reconfiguration, Radio Bearer Set- 
up, Radio Bearer Release, Cell Update, URA Update, 
and UTRAN mobility information) to cause an SRNS Re- 
location procedure to be performed. If the "Downlink 
counter synchronization info" IE is not included, SRNS 
Relocation is not performed. 

[0018] The re-synchronization module 1 01 r of the 
present invention considers two conditions under which 
a PDCP 102 sequence number synchronization proce- 
dure should be performed in response to one of the 
above-noted RRC 101 procedures: 

1) The RRC 101 procedure is combined with an 
SRNS Relocation procedure, and 

2) The RRC 1 01 procedure is performed without an 
SRNS Relocation procedure being performed. 



[0019] With regards to the first condition, the re-syn- 
chronization module 101 r of the present invention in- 
structs the PDC P entity 1 02 to perform a PDC P 1 02 se- 
quence number synchronization procedure if a next ex- 

5 pected UL/DL Receive PDCP sequence number inva- 
lidity event is detected during the SRNS Relocation pro- 
cedure. Otherwise, no PDCP 102 sequence number 
synchronization procedure is performed. With regards 
to the second condition, the re-synchronization module 

io 1 01 r instructs the PDCP entity 1 02 to perform a PDCP 
102 sequence number synchronization procedure only 
if the RLC entity 1 03 of the PDCP entity 1 02 is re-estab- 
lished due to the RRC 101 procedure, or if the PDCP 

102 header compression protocol is caused to be 
is changed by the RRC 101 procedure. In general, the 

RLC entity 1 03 is re-established when the RLC 1 03 PDU 
size is changed by the RRC 101 procedure. 
[0020] In all of the following simplified message se- 
quence charts, it should be noted that the RRC 101 pro- 
cedures covered by the present invention, both in and 
out of combination with an SRNS Relocation procedure, 
are quite complicated and involve large amounts of sig- 
naling. Consequently, the following simplified message 
sequence charts are presented with blocks that repre- 
sent large sections of signaling that are identical to the 
prior art, the details of which are not of direct relevance 
to the present invention. The following simplified mes- 
sage sequence charts are intended to present to one 
reasonably skilled in the art of 3GPP communications 
protocols the pertinent aspects of the present invention 
without undue complexity. 

[0021] Please refer to Fig. 6 with reference to Fig.5. 
Fig. 6 is a simplified message sequence chart for per- 
forming an RRC 101 Cell Update procedure in combi- 
nation with an SRNS Relocation procedure according 
to the present invention. The Cell Update procedure is 
performed when a UE 110a moves into another cell re- 
gion, and is used to update the location of the UE 110a. 
Amongst other things, the RRC 101 Cell Update proce- 
dure is also used to notify the UTRAN of an unrecover- 
able error in an AM RLC 103 entity, to update the 
UTRAN of the current cell the UE 110a is camping on 
after cell reselection, and to act upon a radio link failure. 
Furthermore, the Cell Update procedure may be com- 
bined with a re-establishment procedure for an AM RLC 

103 entity, and RRC 101 Radio Bearer Release, Radio 
Bearer Reconfiguration, Transport Channel Reconfigu- 
ration or Physical Channel Reconfiguration procedures. 
The UE 110a initiates the RRC 101 Cell Update proce- 
dure by sending a Cell Update message 111 to its RRC 
101 peer entity on an SRNS 110c. SRNS 110c deter- 
mines if the UE 1 1 0a needs to be managed by another 
RNS, and thus if an SRNS Relocation procedure needs 
to be performed. Within blocks 112a and 112b, signals 
are passed between the UE 110a, SRNS 110c and a 
TRNS 110b to begin the SRNS Relocation procedure. 
A Cell Update Confirm message 1 13 is then sent by the 
RRC 101 of the TRNS 110b to the corresponding peer 



25 



30 



35 



40 



45 



50 



6 



11 



EP 1 361 706 A2 



12 



entity RRC 1 01 on the UE 1 1 0a, completing the Cell Up- 
date procedure. The Cell Update Confirm message 113 
contains a UL Receive_SN value, which the re-synchro- 
nization module 1 01 r on the UE 110a utilizes. The Cell 
Update Confirm message 113 contains a "Downlink 5 
counter synchronization info" IE to inform the UE 110a 
that an SRNS Relocation procedure is being performed. 
SRNS contexts are forwarded by the SRNS 1 1 0c to the 
TRNS 110b within block 114, followed by the forwarding 
of PDCP SDU data. The RRC 1 01 of the UE 1 1 0a then 10 
sends a UTRAN Mobility Information Confirm message 

115, or another suitable confirmation message, to the 
RRC 101 peer entity on the TRNS 110b, which contains 
a DL Receive_SN value. The DL Receive_SN value is 
used by the re-synchronization module 1 01 r on the is 
TRNS 1 1 0b. Finally, only if the UL Receive_SN value is 
determined by the re-synchronization module 1 01 r of 
the UE 110a to be invalid, i.e., that the re-synchroniza- 
tion module 1 01 r detects that a next expected UL/DL 
Receive PDCP sequence number invalidity event has 20 
occurred, does the re-synchronization module 1 01 r of 

the UE 1 1 0a then instruct the PDCP layer 1 02 to perform 
a PDCP 102 sequence number synchronization proce- 
dure. In this case, the PDCP layer 1 02 of the UE 1 1 0a 
sends a PDCP SeqNum PDU 1 1 6 to its peer entity PD- 25 
CP layer 102 on the TRNS 110b. Otherwise, if no next 
expected UL/DL Receive PDCP sequence number in- 
validity event is detected by the UE 110a re-synchroni- 
zation module 101 r, then the PDCP peer entity 102 on 
the UE 110a does not send the PDCP SeqNum PDU 30 

1 1 6. The above process is performed for all radio bear- 
ers that are configured to support lossless SRNS Relo- 
cation. Similarly, only if the DL Receive_SN value (as 
obtained from the UE 1 1 0a) is determined by the re-syn- 
chronization module 1 01 r of the TRNS 110b to be 35 
invalid, i.e., that the re-synchronization module 1 01 r de- 
tects that a next expected UL/DL Receive PDCP se- 
quence number invalidity event has occurred, does the 
re-synchronization module 1 01 r of the TRNS 110b in- 
struct the PDCP layer 102 to perform a PDCP 102 se- 40 
quence number synchronization procedure, which 
causes the PDCP layer 1 02 of the TRNS 1 1 0b to send 

a PDCP SeqNum PDU 1 1 7 to its peer entity PDCP layer 
102 on the UE 110a. Otherwise, if no next expected UL/ 
DL Receive PDCP sequence number invalidity event is 45 
detected by the TRNS 110b re -synchronization module 
1 01 r, then the PDCP peer entity 1 02 on the TRNS 1 1 0b 
does not send the PDCP SeqNum PDU 1 1 7. As with the 
UE 110a, the above process is performed for all radio 
bearers that are configured to support lossless SRNS so 
Relocation. 

[0022] Please refer to Fig. 7 with reference to Fig. 5. 
Fig. 7 is a simplified message sequence chart for per- 
forming an RRC 101 URA Update procedure in combi- 
nation with an SRNS Relocation procedure according 55 
to the present invention. The URA Update procedure is 
similar to the Cell Update procedure, and is used to in- 
form the UTRAN that its UTRAN Registration Area 



(URA), which consists of several cells, has changed. 
From the point of view of the present invention, the URA 
Update procedure is nearly identical to the Cell Update 
procedure as presented in Fig.6. Briefly, then, the RRC 
101 URA Update procedure is initiated by a UE 120a 
sending a URA Update message 121 to its peer entity 
RRC 101 on an SRNS 120c. The URA Update message 
121 contains an IE that causes SRNS Relocation to be 
performed. A TRNS 120b completes the URA Update 
procedure by sending a URA Update confirm message 
123 to the RRC entity 101 on the UE 120a. The URA 
Update Confirm message contains a UL Receive_SN 
value. Various SRNS Relocation-relate signaling proc- 
esses occur, and finally the RRC 101 of the UE 120a 
sends a UTRAN Mobility Information Confirm message 
125 to the TRNS 120b, which contains a DL 
Receive_SN value. The re-synchronization modules 

101 r of the UE 120a and the TRNS 120b then respec- 
tively utilize the UL Receive_SN value and the DL 
Receive_SN value to determine if they should cause 
their respective PDCP peers 102 to perform a PDCP 

102 sequence number synchronization procedure. A 
PDCP SeqNum PDU 1 26 is sent by the PDCP layer 1 02 
of the UE 120a only if a next expected UL/DL Receive 
PDCP sequence number invalidity event is detected by 
the re-synchronization module 1 01 r of the UE 120a. 
Similarly, a PDCP SeqNum PDU 127 is sent by the PD- 
CP layer 102 of the TRNS 120b only if a next expected 
UL/DL Receive PDCP sequence number invalidity 
event is detected by the re-synchronization module 1 01 r 
of the TRNS 120b. The above process is performed for 
all radio bearers that are configured to support lossless 
SRNS Relocation. 

[0023] Please refer to Fig.8 with reference to Fig.5. 
Fig. 8 is a simplified message sequence chart for per- 
forming an RRC 101 Radio Bearer Setup procedure in 
combination with an SRNS Relocation procedure ac- 
cording to the present invention. Initial signaling related 
to SRNS Relocation is performed between a UE 130a, 
a TRNS 1 30b and an SRNS 1 30c, as i ndicated by boxes 
1 32a and 1 32b. The RRC layer 1 01 of the SRNS 1 30c 
then sends a standard Radio Bearer Setup message 
131 to the UE 110a. The Radio Bearer Setup procedure 
establishes a new radio bearer for transmission and re- 
ception of user data, i.e., transmission alongtheU-plane 
1 04. The radio bearer establishment is based on Quality 
of Service (QoS), and performs assignment of RLC 103 
parameters, multiplexing priority for the Dedicated Traf- 
fic Channel (DTCH), Common Packet Channel (CPCH) 
Set assignment, the scheduling priority for the Dedicat- 
ed Channel (DCH), Transport Format Set (TFS) for the 
DCH, and updating of the Transport Format Combina- 
tion Set (TFCS). The Radio Bearer Setup procedure 
may also include reconfiguration of radio bearers (e.g. 
the assignment of a physical channel, and changing of 
the used transport channel types/RRC 101 state). Note 
that if the SRNS 130c only reconfigures radio bearers, 
then the SRNS 130c normally uses the RRC 101 Radio 
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Bearer Reconfiguration procedure. The Radio Bearer 
Setup message 131 contains an IE that causes SRNS 
Relocation to be performed, and also contains a UL 
Receive_SN value, which is subsequently utilized by the 
re-synchronization module 101 r on the UE 130a. More 5 
SRNS Relocation-related signaling is performed, as in- 
dicated by box 134, culminating in the forwarding of PD- 
CP SDU data from the SRNS 130c to the TRNS 130b. 
Signaling related to detection of the UE 130a by the 
TRNS 130b is performed, as indicated by box 135, and 10 
finally the RRC layer 101 oftheUE 130a completes the 
Radio Bearer Setup procedure by sending a Radio 
Bearer Setup Complete message 136 to its RRC peer 
entity 1 01 on the TRNS 1 30b. The Radio Bearer Setup 
Complete message 136 contains a UL Receive_SN val- 15 
ue, which is subsequently utilized by the re-synchroni- 
zation module 101 r on the TRNS 130b. A PDCP Seq- 
Num PDU 1 37 is sent by the PDCP layer 1 02 of the UE 
130a only if a next expected UL/DL Receive PDCP se- 
quence number invalidity event is detected by the re- 20 
synchronization module 1 01 r of the UE 1 30a. Similarly, 
a PDCP SeqNum PDU 138 is sent by the PDCP layer 
102 of the TRNS 120b only if a next expected UL/DL 
Receive PDCP sequence number invalidity event is de- 
tected by the re-synchronization module 1 01 r of the 25 
TRNS 130b. The re-synchronization modules 101 r 
cause the PDCP 102 sequence number synchroniza- 
tion procedure to be performed (i.e., the sending of the 
PDCP SeqNum PDUs 1 37 and 1 38) on PDCP 1 02 peer 
entities belonging to radio bearers configured to support so 
lossless SRNS Relocation, and which existed before 
performing the Radio Bearer Setup procedure. 
[0024] Please refer to Fig. 9 with reference to Fig.5. 
Fig. 9 is a simplified message sequence chart for per- 
forming an RRC 101 Radio Bearer Release procedure 35 
in combination with an SRNS Relocation procedure ac- 
cording to the present invention. This RRC 101 proce- 
dure releases a radio bearer. The RLC entity 1 03 for the 
radio bearer is thus released as well. The procedure 
may also release a DCH, which affects the TFCS. It may *o 
include release of a physical channel or channels. It may 
also include reconfiguration of radio bearers (e.g. 
changing the used transport channel types/RRC 101 
state). From the standpoint of the present invention, the 
process as performed in Fig.9 is nearly identical to that 45 
of Fig. 8, except that it is performed in the context of a 
Radio Bearer Release message 141, rather than the 
Radio Bearer Setup message 131 , and should be clear 
from Fig.9 to one reasonably skilled in the art. The UL 
Receive_SN value is carried in the initial Radio Bearer so 
Release message 141 to a UE 140a from an SRNS 
140c. The DL Receive_SN value is carried in a Radio 
Bearer Release Complete message 146 to a TRNS 
140b from the UE 140a. The re-synchronization mod- 
ules 101rontheUE 140a and TRNS 140b then respec- 55 
tively use the UL Receive_SN value and the DL 
Receive_SN value to determine if a next expected UL/ 
DL Receive PDCP sequence number invalidity event 



has occurred, and hence if a PDCP 102 sequence 
number synchronization procedure should be per- 
formed by respectively sending a PDCP SeqNum PDU 
147 or 148. As before, PDCP 102 sequence number 
synchronization procedures are only performed if a cor- 
responding next expected UL/DL Receive PDCP se- 
quence number invalidity event is detected. If per- 
formed, the PDCP sequence number synchronization 
procedure is performed on PDCP 102 peer entities be- 
longing to radio bearers configured to support lossless 
SRNS Relocation that have not been released. 
[0025] Please refer to Fig.1 0 with reference to Fig.5. 
Fig. 10 is a message sequence chart for performing an 
RRC 1 01 Transport Channel Reconfiguration procedure 
in combination with an SRNS Relocation procedure ac- 
cording to the present invention. This RRC 101 proce- 
dure reconfigures parameters related to a transport 
channel, such as the TFS. The procedure also assigns 
a TFCS and may change physical channel parameters 
to reflect a reconfiguration of a transport channel in use. 
With respect to the present invention, the procedure is 
nearly identical to those of Fig. 8 and 9, and should be 
clear from Fig.10. PDCP 102 sequence number syn- 
chronization, if performed, is performed for PDCP 102 
peer entities belonging to radio bearers configured to 
support lossless SRNS Relocation. 
[0026] Please refer to Fig. 11 with reference to Fig.5. 
Fig. 11 is a message sequence chart for performing an 
RRC 101 Radio Bearer Reconfiguration procedure in 
combination with an SRNS Relocation procedure ac- 
cording to the present invention. This RRC 101 proce- 
dure reconfigures parameters for a radio bearer (e.g. the 
signaling link) to reflect changes in QoS. It may include 
change of RLC 1 03 parameters, change of multiplexing 
priority for DTCH/DCCH, CPCH Set assignment, 
change of DCH scheduling priority, change of TFS for 
DCH, change of TFCD, assignment or release of phys- 
ical channel or channels, and change of used transport 
channel types. With respect to the present invention, the 
procedure is nearly identical to those of Fig.8, 9 and 10, 
and should be clear from Fig.11. PDCP 102 sequence 
number synchronization, if performed, is performed for 
PDCP 1 02 peer entities belonging to radio bearers con- 
figured to support lossless SRNS Relocation. 
[0027] Please refer to Fig.12 with reference to Fig.5. 
Fig. 12 is a message sequence chart for performing an 
RRC 101 Physical Channel Reconfiguration procedure 
in combination with an SRNS Relocation procedure ac- 
cording to the present invention. The Physical Channel 
Reconfiguration procedure is similar to other reconfigu- 
ration (Radio Bearer Reconfiguration, Transport Chan- 
nel Reconfiguration) procedures, and is used to estab- 
lish, reconfigure, and release physical channels. With 
respect to the present invention, the Physical Channel 
Reconfiguration procedure is nearly identical to those of 
Figs. 8-11, and should be clear from Fig.12. PDCP 102 
sequence number synchronization, if performed, is per- 
formed for PDCP 102 peer entities belonging to radio 
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bearers configured to support lossless SRNS Reloca- 
tion. 

[0028] Please refer to Rg.13 with reference to Fig.5. 
Fig. 13 is a message sequence chart for performing an 
RRC 101 UTRAN Mobility Information procedure in 5 
combination with an SRNS Relocation procedure ac- 
cording to the present invention. The UTRAN Mobility 
Information procedure is used to allocate any one or a 
combination of a new C-RNTI, a new URNTI, and pro- 
vide other mobility related information. With respect to 10 
the present invention, the procedure is nearly identical 
to those of Figs. 8-1 2, and should be clear from Fig. 13. 
PDCP 102 sequence number synchronization, if per- 
formed, is performed for PDCP 1 02 peer entities belong- 
ing to radio bearers configured to support lossless is 
SRNS Relocation. 

[0029] Please refer to Fig. 14 with reference to Fig.5. 
Fig. 14 is a first simplified message sequence chart ac- 
cording to the present invention for performing an RRC 
101 Radio Bearer Reconfiguration procedure without 20 
performing an SRNS Relocation procedure. The RRC 
layer 101 on an SRNS 190b sends a standard Radio 
Bearer Reconfiguration message 1 91 to a UE 1 90a. The 
RRC 101 of the UE 190a responds with a standard Ra- 
dio Bearer Reconfiguration Complete message 192. If, 25 
for example, the Radio Bearer Reconfiguration mes- 
sage 191 contains an IE about the RLC 103 PDU size, 
then the peer entity RLC layers 1 03 on the U E 1 90a and 
SRNS 190b will be re-established, as indicated by the 
dotted boxes 1 93a and 1 93b. When the peer entity RLC 30 
layers 103 are re-established, any RLC 103 PDUs that 
are still in the RLC 1 03 transmission buffers are discard- 
ed, thus causing loss of PDCP 102 PDUs. If the RLC 
layer 103 of the UE 190a is re-established due to the 
RRC 1 01 Radio Bearer Reconfiguration procedure, the 35 
re-synchronization module 1 01 r of the UE 190a will 
cause the PDCP layer 102 of the re-established RLC 
layer 103 to perform a PDCP 102 sequence number 
synchronization procedure, thereby resulting in the PD- 
CP layer 1 02 of the UE 1 90a sending a PDCP SeqNum 40 
PDU 194. This ensures that any lost PDCP 102 PDUs 
are recaptured. If the UE 190a RLC layer 103 is not re- 
established (and the PDCP 102 header compression 
protocol is not changed by the Radio Bearer Reconfig- 
uration procedure), then no PDCP SeqNum PDU 194 is 45 
sent to the SRNS 190b. Similarly, if the RLC layer 103 
of the SRNS 190b is re-established due to the RRC 1 01 
Radio Bearer Reconfiguration procedure, the re-syn- 
chronization module 1 01 r of the SRNS 190b will cause 
the PDCP layer 1 02 of the re-established RLC layer 1 03 so 
to perform a PDCP 1 02 sequence number synchroniza- 
tion procedure, thereby resulting in the PDCP layer 1 02 
of the SRNS 1 90b sending a PDCP SeqNum PDU 1 95, 
and so ensuring recapture of any lost PDCP 1 02 PDUs. 
If the SRNS 190b RLC layer 103 is not re-established 55 
(and the PDCP 102 header compression protocol is not 
changed by the Radio Bearer Reconfiguration proce- 
dure), then the re-synchronization module 1 01 r does not 



force a PDCP 102 sequence number synchronization 
procedure, and so no PDCP SeqNum PDU 195 is sent 
to theUE 190a. 

[0030] Please refer to Fig. 15 with reference to Fig.5. 
Fig. 15 is a second simplified message sequence chart 
according to the present invention for performing an 
RRC 1 01 Radio Bearer Reconfiguration procedure with- 
out performing an SRNS Relocation procedure. The 
RRC layer 1 01 on an SRNS 200b sends a standard Ra- 
dio Bearer Reconfiguration message 201 to a UE 200a. 
The RRC 101 of the UE 200a responds with a standard 
Radio Bearer Reconfiguration Complete message 202. 
If, for example, the Radio Bearer Reconfiguration mes- 
sage 201 contains an IE about the PDCP 102 header 
compression protocol, then the peer entity PDCP layers 
102 on the UE 200a and SRNS 200b will change their 
PDCP 102 header compression protocols, as indicated 
by the dotted boxes 203a and 203b. When the PDCP 
102 header compression protocol is changed, PDCP 
1 02 PDUs that used the old header compression proto- 
col are discarded. If the PDCP 102 header compression 
protocol of the UE 200a is changed due to the RRC 1 01 
Radio Bearer Reconfiguration procedure, the re-syn- 
chronization module 101rof theUE 200a will cause the 
PDCP layer 102 whose header compression protocol 
has changed to perform a PDCP 1 02 sequence number 
synchronization procedure, thereby resulting in the PD- 
CP layer 1 02 of the UE 200a sending a PDCP SeqNum 
PDU 204, and so recapturing any lost PDCP 102 PDUs. 
If the UE 200a PDCP 1 02 header compression protocol 
is not changed (and the corresponding RLC entity 103 
has also not been re-established by the Radio Bearer 
Reconfiguration procedure, as per Fig.14), then no PD- 
CP SeqNum PDU 1 94 is sent to the SRNS 1 90b. Simi- 
larly, if the header compression protocol of the PDCP 
layer 1 02 of the SRNS 200b is changed due to the RRC 
101 Radio Bearer Reconfiguration procedure, the re- 
synchronization module 101r of the SRNS 200b will 
cause the PDCP layer 102 whose header compression 
protocol has changed to perform a PDCP 1 02 sequence 
number synchronization procedure, thereby resulting in 
the PDCP layer 1 02 of the SRNS 200b sending a PDCP 
SeqNum PDU 205. If the header compression protocol 
of the SRNS 200b PDCP layer 1 02 is not changed (and 
if the Radio Bearer Reconfiguration procedure did not 
cause the RLC entity 103 to be re-established, as per 
Fig.14), then the re-synchronization module 1 01 r does 
not force a PDCP 102 sequence number synchroniza- 
tion procedure, and so no PDCP SeqNum PDU 205 is 
sent to the UE 200a. 

[0031] In addition to the RRC 101 Radio Bearer 
Reconfiguration procedure, the present invention con- 
siders additional RRC 101 procedures that can be per- 
formed without an SRNS Relocation procedure. In par- 
ticular, these RRC 1 01 procedures include the Transport 
Channel Reconfiguration, Radio Bearer Setup, Radio 
Bearer Release, and Cell Update procedures. All of 
these RRC 101 procedures are characterized in that 
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they can cause re-establishment of the RLC 103 peer 
entities, and can also cause changes to the PDCP 1 02 
header compression protocol. Hence, from the stand- 
point of the present invention, these RRC 101 proce- 
dures can be treated identically to the Radio Bearer 5 
Reconfiguration procedure, as described with reference 
to Figs. 14 and 15. 

[0032] With the above in mind, the following figures 
are presented to illustrate the present invention with re- 
gards to these RRC 101 procedures. Fig. 16 is afirstsim- 10 
plified message sequence chart according to the 
present invention for performing an RRC 101 Transport 
Channel Reconfiguration procedure without performing 
an SRNS Relocation procedure. As in Fig. 14, if the 
Transport Channel Reconfiguration procedure causes 15 
the RLC 1 03 peer entities to be re-established, then the 
re-synchronization modules 101 r cause a PDCP 102 
sequence number synchronization procedure to be per- 
formed. Otherwise, no PDCP 102 sequence number 
synchronization procedure is performed (assuming that 20 
the PDCP 102 header compression protocol is not 
changed by the Transport Channel Reconfiguration pro- 
cedure). 

[0033] Fig. 17 is a first simplified message sequence 
chart according to the present invention for performing 25 
an RRC 101 Radio Bearer Setup procedure without per- 
forming an SRNS Relocation procedure, and is analo- 
gous to Figs. 14 and 16. Fig. 18 is a second simplified 
message sequence chart according to the present in- 
vention for performing an RRC 1 01 Radio Bearer Setup 30 
procedure without performing an SRNS Relocation pro- 
cedure, and is analogous to Figs. 15 and 17. Fig. 19 is a 
first simplified message seq uence chart according to the 
present invention for performing an RRC 101 Radio 
Bearer Release procedure without performing an SRNS 35 
Relocation procedure, and Fig. 20 is a second simplified 
message sequence chart according to the present in- 
vention for performing an RRC 101 Radio Bearer Re- 
lease procedure without performing an SRNS Reloca- 
tion procedure. Finally, Fig.21 is a first simplified mes- 40 
sage sequence chart according to the present invention 
for performing an RRC 101 Cell Update procedure with- 
out performing an SRNS Relocation procedure, and Fig. 
22 is a second simplified message sequence chart ac- 
cording to the present invention for performing an RRC 45 
1 01 Cell Update procedure without performing an SRNS 
Relocation procedure. 

[0034] In contrast to the prior art, the present inven- 
tion provides a re-synchronization module in the RRC 
layer that performs a PDCP sequence number synchro- 50 
nization process only when a next expected UL/DL Re- 
ceive PDCP sequence number invalidity event is detect- 
ed during the SRNS Relocation procedure, or when an 
RRC procedure, without performing an SRNS Reloca- 
tion procedure, is performed that causes re-establish- 55 
ment of the RLC layer or change to the PDCP header 
compression protocol. Further, PDCP sequence 
number synchronization procedures are performed not 



just for the Radio Bearer Reconfiguration procedure, but 
also for Transport Channel Reconfiguration, Radio 
Bearer Setup, Radio Bearer Release, Cell Update, URA 
Update and UTRAN mobility information procedures. 



Claims 

1 . A method for determining triggering of a packet data 
convergence protocol (PDCP) sequence number 
synchronization procedure in a wireless device, the 
wireless device utilizing a multi-layered protocol 
that includes: 

a radio resource control (RRC) layer for estab- 
lishing and configuring radio links according to 
a plurality of RRC procedures; 
a PDCP layer for transfer of user data between 
users of PDCP services to generate corre- 
sponding PDCP protocol data units (PDUs); 
and 

a radio link control (RLC) layer for segmenting 
the PDCP PDUs for a medium access control 
(MAC) layer; 

the method comprising: 

identifying execution of an RRC procedure, the 
RRC procedure capable of triggering a serving 
radio network subsystem (SRNS) relocation 
procedure; 

if the RRC procedure triggers an SRNS reloca- 
tion procedure, then triggering a PDCP se- 
quence number synchronization procedure on- 
ly if a next expected UL/DL Receive PDCP se- 
quence number invalidity event is detected dur- 
ing the SRNS relocation procedure; and 
if the RRC procedure does not trigger an SRNS 
relocation procedure, then triggering a PDCP 
sequence number synchronization procedure 
only if an RLC entity of a PDCP entity is re-es- 
tablished in response to the RRC procedure, or 
if a PDCP header compression protocol of the 
PDCP entity is changed in response to the RRC 
procedure. 

2. The method of claim 1 further comprising not trig- 
gering a PDCP sequence number synchronization 
procedure if the RRC procedure is incapable of trig- 
gering an SRNS relocation procedure. 

3. The method of claim 1 wherein the RRC procedure 
is further capable of causing the RLC entity of the 
PDCP entity to be re-established. 

4. The method of claim 1 wherein the RRC procedure 
is further capable of causing the PDCP header com- 
pression protocol of the PDCP entity to be changed. 
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5. The method of claim 1 wherein the RRC procedure 
is selected from a set consisting of Transport Chan- 
nel Reconfiguration, Radio Bearer Setup, Radio 
Bearer Release, Cell Update, RRC Radio Bearer 
Reconfiguration, URA Update, and UTRAN Mobility 5 
Information procedures. 

6. The method of claim 1 wherein a PDCP sequence 
number synchronization procedure is triggered only 

if a PDCP PDU is not transmitted successfully by w 
the RLC entity and the RLC entity is re-established 
in response to the RRC procedure. 

7. The method of claim 1 wherein a PDCP sequence 
number synchronization procedure is triggered only is 
if a PDCP PDU is not transmitted successfully by 

the RLC entity and the PDCP header compression 
protocol of the PDCP entity is changed in response 
to the RRC procedure. 

20 

8. An improved wireless device comprising a packet 
data convergence protocol (PDCP) re-synchroniza- 
tion module for performing the following steps: 



be changed. 

The wireless device of claim 8 wherein the RRC 
procedure is selected from a set consisting of 
Transport Channel Reconfiguration, Radio Bearer 
Setup, Radio Bearer Release, Cell Update, RRC 
Radio Bearer Reconfiguration, URA Update, and 
UTRAN Mobility Information procedures. 

The wireless device of claim 8 wherein a PDCP se- 
quence number synchronization procedure is trig- 
gered by the PDCP re-synchronization module only 
if a PDCP PDU is not transmitted successfully by 
the RLC entity and the RLC entity is re-established 
in response to the RRC procedure. 

The wireless device of claim 8 wherein a PDCP se- 
quence number synchronization procedure is trig- 
gered by the PDCP re-synchronization module only 
if a PDCP PDU is not transmitted successfully by 
the RLC entity and the PDCP header compression 
protocol of the PDCP entity is changed in response 
to the RRC procedure. 



identifying execution of a radio resource control 25 
(RRC) procedure by the wireless device, the 
RRC procedure capable of triggering a serving 
radio network subsystem (SRNS) relocation 
procedure; 

if the RRC procedure triggers an SRNS reloca- so 
tion procedure, then triggering a PDCP se- 
quence number synchronization procedure on- 
ly if a next expected UL/DL Receive PDCP se- 
quence number invalidity event is detected dur- 
ing the SRNS relocation procedure; and 35 
if the RRC procedure does not trigger an SRNS 
relocation procedure, then triggering a PDCP 
sequence number synchronization procedure 
only if a radio link control (RLC) entity of a PD- 
CP entity supported by the wireless device is 40 
re-established in response to the RRC proce- 
dure, or if a PDCP header compression proto- 
col utilized by the PDCP entity is changed in 
response to the RRC procedure. 

45 

9. The wireless device of claim 8 wherein the PDCP 
re-synchronization module does not trigger a PDCP 
sequence number synchronization procedure if the 
RRC procedure is incapable of triggering an SRNS 
relocation procedure. so 



10. The wireless device of claim 8 wherein the RRC 
procedure is further capable of causing the RLC en- 
tity of the PDCP entity to be re-established. 

11. The wireless device of claim 8 wherein the RRC 
procedure is further capable of causing the PDCP 
header compression protocol of the PDCP entity to 
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